What & why

Approximate MATCH, VLOOKUP, HLOOKUP and XLOOKUP returned #N/A (or, in descending mode, the wrong position) when the sorted search range contained genuinely empty cells. Excel 2021 and Google Sheets skip empty cells when computing the lower/upper bound; HyperFormula instead landed on an empty cell during binary search (its EmptyValue Symbol never matched the key). [HF-223]

Root cause

findLastOccurrenceInOrderedRange (src/interpreter/binarySearch.ts): compare() ranks EmptyValue below every value, breaking the sort invariant the binary search relies on, and the typeof foundValue !== typeof searchKey guard then turned a landing-on-empty into #N/A. Shared by approximate MATCH(±1), sorted VLOOKUP/HLOOKUP, and XLOOKUP(searchMode ±2).

Fix

• The binary search runs directly over the original range while tracking whether the descent ever probes an empty cell. Empty cells are the only source of non-monotonicity in the search predicate, so a descent that never touches one is provably equivalent to a search over the range with empty cells removed and its result is trusted as-is — the common case stays O(log n), including ranges that contain empty cells the descent happens not to touch.
• Only when the descent probes an empty cell does the search fall back to an O(n) compaction: the non-empty cell indices are collected, the binary search re-runs over the compacted list, and the result maps back to the original index space, so empty cells keep their slots and the matched non-empty cell's original 1-based position is reported unchanged. (In exact-match mode, a hit found by the direct descent is accepted after an equality re-check, skipping the fallback.)
• The "no match at all" bound cases return the position of the first non-empty cell (never the position of a leading empty cell), and the approximate-bound "next" position steps to the next non-empty index, so skipped empty slots never shift the reported position.
• AdvancedFind.findNormalizedValue skips EmptyValue on its in-memory ordered path for the same reason, keeping the linear and binary search modes consistent.
• A matched result cell that is empty is returned as 0 (zeroIfEmptyResult), matching Excel, for VLOOKUP/HLOOKUP/XLOOKUP including multi-cell XLOOKUP return arrays.
• Empty strings are unaffected (text ranks above numbers, so they still terminate a numeric run).

Performance & edge cases

• Complexity: O(log n) whenever the binary-search descent probes no empty cell (always the case for gap-free ranges — the typical sorted-lookup workload); O(n) only when an empty cell actually interferes with the descent. A new Sorted lookup benchmark in the performance suite guards this fast path.
• All-empty range: returns NOT_FOUND directly (the if_not_found result / #N/A), never row 1.
• Leading empty cells with the key outside the range: the bound modes return the first non-empty position, consistent with the linear search modes on the same data.
• Duplicates caveat: in exact-match binary modes, when the range contains both duplicates of the key and interspersed empty cells, which duplicate is reported is unspecified (Excel's binary modes likewise leave this unspecified); documented in the function's JSDoc.

Excel / Google Sheets parity

Behaviour verified against the latest Excel and Google Sheets, including exact-vs-blank, empty-string-not-skipped, and the descending early-stop case. For the leading-empty bound cases, HyperFormula's binary modes are consistent with its own linear modes (Excel documents binary search over blank-containing ranges as unreliable).

Tests

Public test suite: handsontable/hyperformula-tests#17 (matching branch task/hf-223-match-empty-cells), including regression locks for the stepping and leading-empty edge cases and a Sorted lookup performance benchmark.

Definition of Done

• Production code + JSDoc
• Tests (hyperformula-tests#17, matching branch)
• Changelog (empty-cell search fix + empty-result → 0 coercion)
• i18n — N/A (shared-logic fix, no function add/rename)
• Docs — list-of-differences entry for the remaining Excel divergence